얼마 전, '스마트 어라운드'라는 신규 프로젝트를 릴리즈했다. 처음 맡은 신규 프로젝트였기에, 욕심도 많았고 아쉬움도 많았다. 프로젝트가 끝난 후, 팀원들과 함께 회고를 진행했고 그 이야기를 해보려고 한다.
회고 준비
회고를 준비하는 그 첫번째 단계로 회고에 대해 알아보고 그 방법에는 어떤 것들이 있는지에 대해 알아보았다. 프로젝트 회고를 준비하면서 여러 회고 글들을 보게 되었는데, 보통 '회고란 무엇인가'로 시작하더라. 팀 내에 통일화 된 회고의 의미를 정의하는 것이 우선이겠다 싶어, **'5W1H원칙'**에 따라 정리해보았다. (Where은 생략!)
What, 회고란 무엇인가
회고의 사전적 정의를 먼저 살펴보면, "돌아다봄", "지나간 일을 돌이켜 생각함" 등을 의미한다.
이를 **'프로젝트 회고'**라는 부분으로 구체화시켜 의역을 해봤다. 프로젝트 회고란 프로젝트의 생명 주기에서 특정 시점에 진행하는 회의의 일종이라고 할 수 있다. 수많은 회의의 연속이기 때문에 프로젝트 구성원끼리 Why를 잘 정의해야 하고 How를 잘 따라야 '좋은 회고'가 될 수 있다.
When, 회고는 언제 하는가
What에서 언급한 **'특정 시점'**은 프로젝트 구성원들이 협의하여 지정한다. 애자일스러운 회고를 한다면 이터레이션(iteration) 또는 스프린트(sprint)라는 주기마다 진행할 수 있다.
우리 프로젝트는 회고가 정식적으로 계획된 것이 아니어서 프로젝트가 1.0.0 으로 릴리즈가 되고 난 후, 회고를 진행하게 되었다. 즉 스마트 어라운드 프로젝트 회고 시점은 1차 스펙이 릴리즈 되고 난 후가 되겠다.
Who, 회고는 누가 하는가?
이 역시 '프로젝트 회고'에 국한하여 살펴보자면 기본적으로 프로젝트에 참여한 사람들이 하게 된다. 퍼실리테이터(facilitator)가 함께 회고에 참여하여 회의를 이끌어준다면 좋겠지만 그런 경우는 거의 드물기 때문에 이미 회고 경험이 있는 사람이 이끄는 것도 좋은 방법이 될 수 있다. 그러나 가장 중요한 것은 회고를 하는 이유가 내재화 된 사람들과 진행해야 한다.
Why, 회고는 왜 하는가?
회고를 진행하기 전, 프로젝트 팀원들이 모여 **'우리는 이 회고를 왜 해야하는가'**에 대해 집중적으로 고민을 하고 회고를 진행해야 한다. 구성원들이 생각하고 있는 회고가 다를 수 있다. 어떠한 피드백 또는 결과물을 원하는지 다를 수 있다. 그렇기 때문에 이 과정은 회고 프로세스 상 가장 중요한 과정이며 꼭 포함시켜야 하는 부분이다.
정작 필요한 것이 회고가 아닐 수 있다. 여러 이유로 잠깐의 break time이 필요할 수도 있고 일정을 되돌아보고 스펙 조정이 필요할 수도 있다. 하지만 이것들은 회고로부터 도출된 것들의 후속 회의이다.
우리 팀은 Why에 대해 다음과 같이 합의하고 회고에 임했다.
하나의 이터레이션 또는 프로젝트 릴리즈 후 회고의 시간을 가짐으로써 지난 시간동안 '잘 된 점'과 '아쉬운 점', 그에 따른 후기 등을 서로 공유할 수 있다. 이를 기반으로 아쉬웠던 부분을 바로잡고 프로젝트가 좋은 방향으로 발전할 수 있도록 한다. 이는 중간 점검의 일종으로 볼 수 있지만 '프로젝트가 어느 정도 진행되었는가' 와는 별도로 진행되어야 한다.
How, 회고는 어떻게 할 수 있나? - 프로세스
우선 구성원들이 회고에 대해 동일하게 이해해야 하며, 이를 바탕으로 공동 목표를 수립해야 한다. 그리고 나서 어떤 방식으로 회고를 할 것인가에 대해 논의해야 한다. 이것은 회고 참여자들끼리 정하기 나름이다. 바로 함께 회고를 시작하기 보다는 각자만의 회고를 진행한 후, 함께 회고를 하는 것이 좋다. 분위기에 휩쓸려 미처 말하지 못하고 넘어가는 것이 있으면 그것이 문제가 될 수 있다.
우리 팀은 문제라고 인식된 이슈를 사전에 파악할 수 없었는지에 대해 집중을 해보았다. 왜 파악할 수 없었으며 진행되는 프로젝트 주기 상, 동일한 이슈를 겪지 않으려면 어떠한 action item을 도출해야 하는지에 대해 포커싱하였다. 물론 각자만의 회고 시간을 가졌고 회고는 다음 두 방법으로 진행하였다.
How, 회고의 방법론
회고를 할 수 있는 여러 가지 방법이 있다. 그 중 실제로 사용한 방법인 두 가지를 소개하고자 한다.
타임라인 리뷰
말 그대로 프로젝트의 흐름을 처음부터 짚어가며 회고를 진행하는 방법이다. 우리 팀의 경우에는 프로젝트 Repository에 등록된 이슈(issue)의 흐름을 따라 회고를 진행했다. 약간이라도 논의가 필요하거나 문제가 될만한 것들은 이슈로 등록해두었기 때문에 이슈로도 흐름을 파악하기에 충분했다. 해당 시기에 무엇을 했는지 보다 구체적으로 알아야 하는 경우에는 커밋 히스토리를 열어 어떠한 작업이 진행되었는지 파악했다. 이 흐름을 주 단위로 나누고 주마다 어떠한 점이 아쉬웠고 어떤 부분이 좋았는지 정리를 했다.
처음에는 타임라인을 화이트보드에 전부 그렸다. 발생했던 이슈들도 보기 좋게 다 적어두었다. 그리고 좋았던 점은 노란 포스트잇에 적어 붙이고 아쉬웠던 점은 파란 포스트잇에 적어 붙였다. 이렇게 진행하다보니 반 정도 진행했을 때 팔이 아파오기 시작했다. 시간도 너무 오래 걸렸다.
채워져가는 화이트 보드를 보며 뿌듯했지만 결국 트렐로(Trello)로 넘어가서 진행했다. column에 타임라인을 정리하고 카드를 통해 발생한 이슈를 정리했다. 특정 이슈에 대해 좋았던 점과 아쉬웠던 점은 comment를 통해 기록했다. (처음부터 프로젝터를 하나 띄워두고 트렐로로 진행하기를 추천한다.)
KPT 방법론
KPT는 Keep, Problem, Try 의 약자이다. 각각은 item이 될 수도 있고 특정 사건이 될 수 있다. 다음 프로젝트를 진행할 때도 유지할 것(Keep), 프로젝트를 진행하면서 문제가 되었던 것(Problem), 다음 프로젝트 진행 시 시도할 것(Try)으로 구분지어 회고하는 것이다.
Problem을 정의할 때는 발생한 이슈 뿐만 아니라 문제로 도달하는 과정에 대해 쓰는 것이 좋다. 그리고 도출되는 Try는 구체적일수록 좋다.
우리 팀은 타임라인 리뷰를 마치고 나온 comment(좋았던 점, 아쉬웠던 점)를 기반으로 진행하였다. 좋았던 점 중에 유지할 것은 Keep에 넣고 아쉬웠던 점을 Problem으로 정의했다. 아쉬웠던 점들에 대해 원인을 분석하고 기반으로 Try를 정리하여 추후 Action Item을 정의했다.
대부분의 problem은 일정 상의 문제, 사전 커뮤니케이션의 부재 등이었다. 이를 사전에 방지할 수는 없었는지 파악해보고 이를 방지하기 위해서는 어떤 action item을 try 할 지 고민하였다.
How, 회고의 진실
사실 회고는 무엇을 해야하는가보다 무엇을 하지 말아야 하는가가 더 중요하다. 조심해야 할 것도 많고 해서는 안 되는 것들도 있다.
만약 회고 시간 때 다음과 같은 주제를 거론하고 싶다면, 별도의 회의 시간을 잡자.
- 코드 상의 구조 설계를 다시 잡아보자
- 코드 스타일 논의하자
- 현재 진행 상황을 돌이켜보고 앞으로 남은 일정을 어떻게 분배할지 정해보자
에디터를 열지 말고 코드를 열지 말자. 코드 리딩 또는 코드 리뷰는 별도의 시간을 내어 진행하는 것이 바람직하다. 코드에 대한 질문과 그 답변이 오가는 순간 코드 리뷰 시간이 되어버린다.
'기본적인' 커뮤니케이션은 기본이 되겠다.
마무리
프로젝트가 어디까지 왔는가보다 어떻게 왔는가에 집중하고 어디로 갈지 보다는 어떻게 갈 것인가를 고민하는 시간이 된다면 회고는 성공적일 것이다. 요약된 내용은 이슈에서 확인할 수 있다.